An electronic behavioral health record (eBHR) has an additional privacy constraint due to 42-CFR Part II that requires consent before federal funded substance abuse programs can disclose a patient’s identify. However, an eBHR can be shared similar to other types of health records once proper consent is acquired. Data is electronically shared on a Health Information Exchange (HIE) and there are two types of HIE models where this occurs. Additional agreements related to the operation of the HIE are required depending on what model HIE the information is shared on. HIEs have consent models that define implicit patient consent on participating patient records. For 42 CFR Part II, the HIE consent model must require patient consent before an eBHR would be disclosed to a new entity. Recommendations
Incorporate, don’t replace existing patient consent processes for 42-CFR Part II with an HIE
Ensure that the HIE’s consent model requires patient consent for providers to subsequently re-disclosure to other providers of information
Ensure that patient consent can be updated
Introduction
The ONC’s publication describes how consent is implemented within the existing electronic health information exchange (HIE) landscape of 2010. The SAMHSA publication applies 42-CFR Part II non-disclosure requirements to an electronic behavioral health record (eBHR).
Three key finding from the SAMHSA publication are specifically addressed in this paper on the feasibility of eBHR sharing.
#
42-CFR Finding
Addressed
11
A Qualified Service Organization Agreement (QSOA) is necessary for eBHR sharing on certain HIEs
“Consent Requirements”
22
Patients can provide consent at the releasing agency or requesting agency
“Patient Consent”
33
HIEs are required to enable patient’s to update their consent preferences
“Consent Management”
This paper analyzes the feasibility of sharing an eBHR with-in the 2010 HIE landscape with specific focus on the following four questions.
Given the constraints 42-CFR Part II SAMHSA FAQ, can the behavioral health records of substance abuse patients be shared on an existing HIE?
If so, how would an SSA or County do this in a HIE?
Legal Action Center for the Substance Abuse and Mental Health Services Administration. (2010, 6 17). Frequently Asked Questions: Applying the Substance Abuse Confidentiality Regulations to Health Information Exchange (HIE). Retrieved 10 11, 2010, from The Substance Abuse and Mental Health Services Administration : http://www.samhsa.gov/HealthPrivacy/docs/EHR-FAQs.pdf
Electronic Behavioral Health Record (eBHR) Overview
An electronic behavioral health record (eBHR) is electronic documentation of a patient's medical history and care. In eBHR systems, there are two layers of control that protect patient privacy by limiting access to the eBHR. As displayed in the figure below “Restricting Access to the eBHR”, the first layer of protection is privacy. This layer restricts who can access what aspects of the patient’s record. In the context of a federal funded substance abuse facility, even access to a patient’s name is restricted without patient consent. The final layer of protection is security that consists of technical safeguards designed to prohibit or detect access to a record.
Restricting Access to the eBHR
The electronic behavioral healthrecord is maintained in a restricted manner in which two layers limit the access to the record.
The first is a privacy**[1]** layer that controls the extent in which information can be made available. This is often based on a combination of: roles, patient consent, and Personal Health Information (PHI)
The last layer in a typical eBHR is security**[2]** which is an implementation of technical safeguards such as user-ids/passwords, logging, encryption, and tamper evident hashing.
The 42 CFR Part-II “non-disclosure” constraint
Patient Consent Excluding medical emergencies, patient consent (see 42 CFR Patient Consent (9 required elements)on page 8) is required before a patient’s eBHR can be shared with another provider. Patient consent can be provided at either the releasing agency or the sending agency. In an HIE, two aspects of the patient consent require special attention for sharing an eBHR. The first is the ability for the patient to revoke consent at any point in time. The second is the identification of all parties that disclosure will be made to. This impacts the various types of consent models (see Consent Models page 6) and some of the technology available to share records on an HIE (see Two HIE Models on page 3) Impact to sharing in an HIE
In the absence of patient consent to share records, an additional “non-disclosure” safeguard prevents federally funded substance abuse facilities from acknowledging the existence of a patience record. This safeguard makes the patient invisible to the other providers on the Health Information Exchange (HIE). Requesting organizations should be unaware of a patient existing on the HIE without a patient consenting their eBHR to be disclosed.
This constraint impacts how patient discovery occurs on an HIE. Patient discovery is a transaction consisting of patient identifying information[3] sent by a requesting provider to another provider in order to establish the existence of a patient. This transaction is the root for all subsequent health record requests.
eBHR data sharing in an HIE
Electronic health records are shared on HIEs. Based on the types of HIE, 42-CFR has different constraints on the agreements needed in order to share data. Two HIE Models
The two basic models of health information exchanges are the central data repository (CDR) and federated model (health record messaging). The CDR is a single data repository. In this repository (see Figure 1), the patient’s longitudinal record of care is integrated with multiple organizations. Access to a patient record is centrally managed by a Health Information Organization (HIO) and requires a common understanding of CDR’s data elements between the participating organizations. The federated model (see figure 2), on the other hand, lacks a central repository and participating organizations directly share information with each other through health message containing an interoperable eBHR.
What would data sharing look like in an HIE?
Figure 1 ~ Hub and Spoke Model (CDR)
Figure 2 ~ Federated Model (Health Record Messaging)
Figure 1: The eBHR is centrally located and updated in a central data repository. Access to the patient’s record is centrally controlled
Figure 2: The eBHR is messaged between various nodes in the HIE and not stored in a central repository
Consent Requirements
Based on the type of HIE, there may be different consent required. As mentioned previously, patient consent[4] is required in order for a federally funded substance abuse facility to disclose any aspect of an eBHR including patient name. If an eBHR is exchanged on an HIE that uses a CDR model, two additional agreements (see figure 3) are required. The HIO managing the CDR must have an executed Qualified Service Organization Agreement (QSOA) with the source of the patient eBHR and the patient must additionally consent to the HIO having a copy of their eBHR. The QSOA is typically a one-time agreement between organizations on the HIE that doesn’t need to be created every time a patient provides consent. On the other hand, the federated HIE (as shown in figure 4) does not have an intermediary and therefore doesn’t require additional consent.
Types of Consent Required for 42 CFR Part II
Figure 3 Consent in an Hub and Spoke HIE
Figure 4 Consent in a Federated HIE
In Figure 3: At least 4 agreements are required before a patient’s record can be shared between federally funded substance abuse providers
In Figure 4: The patient just needs to provide consent for the source provider to share their eBHR with another provider.
In addition to explicit patient consent, the HIE (CDR or Federated) will have an implicit type of consent by virtue of the eBHR being share on the exchange called a consent model. Consent Model
There are five consent models –as displayed in the image below- in a HIE that vary in the spectrum of most restrictive to least restrictive. A consent model defines if and to what extend information can be shared in an HIE. Since 42 CFR requires a patient’s knowledge of the information to be shared with an organization, substance abuse information could only be shared in either an “Opt-In” or more restrictive model. Consent Management After patient consent[5] is given to share an eBHR, there is the potential for circumstances that may cause patients to alter their consent. Therefore it is necessary for HIEs to manage the consent patient have/are giving for their records to be shared. Bottom line The HIE must have a consent model that requires patient consent for subsequent information sharing. Additionally, patients must have the ability to change their privacy preferences.
Exchanging an eBHR
The “non-disclosure” safeguard is not an impediment to sharing an eBHR. Multiple exchange patterns exist for sharing health records. An exchange pattern is a collection of one or more transactions for sharing a health record between systems. Two exchange patterns, in particular, that provide practical solutions to the “non-disclosure” constraint of the eBHR are the Asynchronous patient discovery and Directed Message. Asynchronous patient discovery
An asynchronous patient discovery protects the patient’s anonymity until it is determined that there is appropriate consent to disclose patient information. This is accomplished by separating patient discovery into two separate, independent transactions. The initiating patient discovery is not immediately responded to and the pause allows the provider to manually determine if they have the proper patient consent in order to disclose their information. If there is appropriate consent, the request is responded to. Otherwise the request would remain indefinitely in queue and unacknowledged. Asynchronous patient discovery satisfies eBHR privacy constraints and allows providers to use their own process to manage consent. Directed Message
The directed message is a one-way push of the patient’s health record to a source. This type of exchange is straightforward and eliminates multiple burdens. Similar to when information is shared via other direct channels (primarily fax or mail), the initiator of the transaction is responsible for ensuring proper consent is acquired before sharing information. Furthermore, this reduces complexity around the correct identification of patient data. This type of exchange, however, is dependent on patient pro-actively providing consent and directing their provider to send information. Bottom line:
In either the Asynchronous Patient Discovery or the Directed Message, patient consent is able to be acquired/stored in an “out of band”[6] process. As a result existing consent management processes would likely be compatible with sharing an eBHR electronically.
Conclusion and Recommendations
Sharing an eBHR is initially dependent on data standards. The eBHR safe guards required by 42-CFR Part II do not prohibit electronic sharing of information. An eBHR can be shared on any model of HIE as long as patient consent has been acquired. The consent model of the HIE, however, must require patient consent before records can be shared with other entities. Give that, all consent requirements can be satisfied with existing processes and the same technology for an eHR. Recommendations
Adopt data standards
Incorporate, don’t replace existing patient consent processes for 42-CFR Part II with an HIE
Ensure that the HIE’s consent model requires patient consent for subsequent disclosure of information
Ensure that patient consent can be updated
Appendix
42 CFR Patient Consent (9 required elements)
#
Element Description
1
Program or person permitted to make the disclosure
2
name or title of the individual or the name of the organization to which disclosure is to be made
3
Patient Name
4
purpose of the disclosure
5
What information to be disclosed
6
Consent (signature of patient or guardian)
7
date of consent
8
statement that the consent is subject torevocation at any time
9
Consent expiration (date, event or condition upon which the consent will expire)
[1] dictated by 42 CFR Part II, HIPAA, and GINA [2] dictated by Federal Health Information Processing Standards (FIPS)
[3] Identifying information is typically: First Name, Last Name, Gender, and Date of Birth [4] The signed consent must nine elements (including the patient’s signature and the organization to which disclosure is being made). [5] See Appendix (9 Elements of Consent Given in 42-CFR) [6] “Out of Band” is a term used to indicate an information exchange occurring outside of an HIE, such as paper. [A1]
I have started to address these two items in addition to the way a privacy profile for NHIN could enable Federally Funded SA facilities to exchange eBHRs on current HIEs.
Executive Summary
An electronic behavioral health record (eBHR) has an additional privacy constraint due to 42-CFR Part II that requires consent before federal funded substance abuse programs can disclose a patient’s identify. However, an eBHR can be shared similar to other types of health records once proper consent is acquired. Data is electronically shared on a Health Information Exchange (HIE) and there are two types of HIE models where this occurs. Additional agreements related to the operation of the HIE are required depending on what model HIE the information is shared on. HIEs have consent models that define implicit patient consent on participating patient records. For 42 CFR Part II, the HIE consent model must require patient consent before an eBHR would be disclosed to a new entity.Recommendations
Introduction
The ONC’s publication describes how consent is implemented within the existing electronic health information exchange (HIE) landscape of 2010. The SAMHSA publication applies 42-CFR Part II non-disclosure requirements to an electronic behavioral health record (eBHR).Three key finding from the SAMHSA publication are specifically addressed in this paper on the feasibility of eBHR sharing.
This paper analyzes the feasibility of sharing an eBHR with-in the 2010 HIE landscape with specific focus on the following four questions.
References
Electronic Behavioral Health Record (eBHR) Overview
An electronic behavioral health record (eBHR) is electronic documentation of a patient's medical history and care. In eBHR systems, there are two layers of control that protect patient privacy by limiting access to the eBHR. As displayed in the figure below “Restricting Access to the eBHR”, the first layer of protection is privacy. This layer restricts who can access what aspects of the patient’s record. In the context of a federal funded substance abuse facility, even access to a patient’s name is restricted without patient consent. The final layer of protection is security that consists of technical safeguards designed to prohibit or detect access to a record.The first is a privacy**[1]** layer that controls the extent in which information can be made available. This is often based on a combination of: roles, patient consent, and Personal Health Information (PHI)
The last layer in a typical eBHR is security**[2]** which is an implementation of technical safeguards such as user-ids/passwords, logging, encryption, and tamper evident hashing.
The 42 CFR Part-II “non-disclosure” constraint
Patient ConsentExcluding medical emergencies, patient consent (see 42 CFR Patient Consent (9 required elements)on page 8) is required before a patient’s eBHR can be shared with another provider. Patient consent can be provided at either the releasing agency or the sending agency.
In an HIE, two aspects of the patient consent require special attention for sharing an eBHR. The first is the ability for the patient to revoke consent at any point in time. The second is the identification of all parties that disclosure will be made to. This impacts the various types of consent models (see Consent Models page 6) and some of the technology available to share records on an HIE (see Two HIE Models on page 3)
Impact to sharing in an HIE
In the absence of patient consent to share records, an additional “non-disclosure” safeguard prevents federally funded substance abuse facilities from acknowledging the existence of a patience record. This safeguard makes the patient invisible to the other providers on the Health Information Exchange (HIE). Requesting organizations should be unaware of a patient existing on the HIE without a patient consenting their eBHR to be disclosed.
This constraint impacts how patient discovery occurs on an HIE. Patient discovery is a transaction consisting of patient identifying information[3] sent by a requesting provider to another provider in order to establish the existence of a patient. This transaction is the root for all subsequent health record requests.
eBHR data sharing in an HIE
Electronic health records are shared on HIEs. Based on the types of HIE, 42-CFR has different constraints on the agreements needed in order to share data.Two HIE Models
The two basic models of health information exchanges are the central data repository (CDR) and federated model (health record messaging). The CDR is a single data repository. In this repository (see Figure 1), the patient’s longitudinal record of care is integrated with multiple organizations. Access to a patient record is centrally managed by a Health Information Organization (HIO) and requires a common understanding of CDR’s data elements between the participating organizations. The federated model (see figure 2), on the other hand, lacks a central repository and participating organizations directly share information with each other through health message containing an interoperable eBHR.
Figure 1 ~ Hub and Spoke Model (CDR)
Figure 2 ~ Federated Model (Health Record Messaging)
Figure 2: The eBHR is messaged between various nodes in the HIE and not stored in a central repository
Consent Requirements
Based on the type of HIE, there may be different consent required. As mentioned previously, patient consent[4] is required in order for a federally funded substance abuse facility to disclose any aspect of an eBHR including patient name. If an eBHR is exchanged on an HIE that uses a CDR model, two additional agreements (see figure 3) are required. The HIO managing the CDR must have an executed Qualified Service Organization Agreement (QSOA) with the source of the patient eBHR and the patient must additionally consent to the HIO having a copy of their eBHR. The QSOA is typically a one-time agreement between organizations on the HIE that doesn’t need to be created every time a patient provides consent. On the other hand, the federated HIE (as shown in figure 4) does not have an intermediary and therefore doesn’t require additional consent.
Figure 3 Consent in an Hub and Spoke HIE
Figure 4 Consent in a Federated HIE
In addition to explicit patient consent, the HIE (CDR or Federated) will have an implicit type of consent by virtue of the eBHR being share on the exchange called a consent model.
Consent Model
There are five consent models –as displayed in the image below- in a HIE that vary in the spectrum of most restrictive to least restrictive. A consent model defines if and to what extend information can be shared in an HIE. Since 42 CFR requires a patient’s knowledge of the information to be shared with an organization, substance abuse information could only be shared in either an “Opt-In” or more restrictive model.
Consent Management
After patient consent[5] is given to share an eBHR, there is the potential for circumstances that may cause patients to alter their consent. Therefore it is necessary for HIEs to manage the consent patient have/are giving for their records to be shared.
Bottom line
The HIE must have a consent model that requires patient consent for subsequent information sharing. Additionally, patients must have the ability to change their privacy preferences.
Exchanging an eBHR
The “non-disclosure” safeguard is not an impediment to sharing an eBHR. Multiple exchange patterns exist for sharing health records. An exchange pattern is a collection of one or more transactions for sharing a health record between systems. Two exchange patterns, in particular, that provide practical solutions to the “non-disclosure” constraint of the eBHR are the Asynchronous patient discovery and Directed Message.Asynchronous patient discovery
An asynchronous patient discovery protects the patient’s anonymity until it is determined that there is appropriate consent to disclose patient information. This is accomplished by separating patient discovery into two separate, independent transactions. The initiating patient discovery is not immediately responded to and the pause allows the provider to manually determine if they have the proper patient consent in order to disclose their information. If there is appropriate consent, the request is responded to. Otherwise the request would remain indefinitely in queue and unacknowledged. Asynchronous patient discovery satisfies eBHR privacy constraints and allows providers to use their own process to manage consent.
Directed Message
The directed message is a one-way push of the patient’s health record to a source. This type of exchange is straightforward and eliminates multiple burdens. Similar to when information is shared via other direct channels (primarily fax or mail), the initiator of the transaction is responsible for ensuring proper consent is acquired before sharing information. Furthermore, this reduces complexity around the correct identification of patient data. This type of exchange, however, is dependent on patient pro-actively providing consent and directing their provider to send information.
Bottom line:
In either the Asynchronous Patient Discovery or the Directed Message, patient consent is able to be acquired/stored in an “out of band”[6] process. As a result existing consent management processes would likely be compatible with sharing an eBHR electronically.
Conclusion and Recommendations
Sharing an eBHR is initially dependent on data standards. The eBHR safe guards required by 42-CFR Part II do not prohibit electronic sharing of information. An eBHR can be shared on any model of HIE as long as patient consent has been acquired. The consent model of the HIE, however, must require patient consent before records can be shared with other entities. Give that, all consent requirements can be satisfied with existing processes and the same technology for an eHR.Recommendations
Appendix
42 CFR Patient Consent (9 required elements)
[1] dictated by 42 CFR Part II, HIPAA, and GINA
[2] dictated by Federal Health Information Processing Standards (FIPS)
[3] Identifying information is typically: First Name, Last Name, Gender, and Date of Birth
[4] The signed consent must nine elements (including the patient’s signature and the organization to which disclosure is being made).
[5] See Appendix (9 Elements of Consent Given in 42-CFR)
[6] “Out of Band” is a term used to indicate an information exchange occurring outside of an HIE, such as paper.
[A1]
I have started to address these two items in addition to the way a privacy profile for NHIN could enable Federally Funded SA facilities to exchange eBHRs on current HIEs.